home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Secrets 4 / Hacker's Secrets 4.iso / misc / skeyfl~1.txt < prev    next >
Text File  |  1996-04-26  |  11KB  |  300 lines
  1.  
  2.              VULNERABILITIES IN THE S/KEY ONE TIME PASSWORD SYSTEM
  3.                                        
  4.    Author: Mudge
  5.    Organization: L0pht Heavy Industries (aka l0pht.com)
  6.    
  7.      _________________________________________________________________
  8.    
  9.    This may be redistributed as long as proper credit is maintained. In
  10.    other words... if you like it don't try to take credit for it. If you
  11.    don't like it don't take credit for it.
  12.      _________________________________________________________________
  13.    
  14.    This paper is still under revision and modification. If you have any
  15.    comments or feedback please e-mail me.
  16.    
  17.    
  18.      _________________________________________________________________
  19.    
  20. Intro
  21.  
  22.    
  23.      _________________________________________________________________
  24.    
  25.    [note: This is not intended to be an extensive introduction on how to
  26.    use the s/key package. For this there are several good resources
  27.    available on the net. What this paper attempts to do is to quickly
  28.    summarize what some of s/key's vulnerabilities are.]
  29.    
  30.    Being sniffed is the sys-admin / security specialists worst nightmare.
  31.    For those that aren't privy, sniffing is slang for placing a network
  32.    card into promiscuous mode so that it actually looks at all of the
  33.    traffic coming along the line and not just the packets that are
  34.    addressed to it. By doing this one can catch passwords, login names,
  35.    confidential information, etc. Of course there are good sides to being
  36.    able to place a card into promiscuous mode such as traffic analysis,
  37.    debugging drivers and network applications, and testing router
  38.    configurations to name just a few. In promiscuous mode anything that
  39.    goes by in plaintext is fair game. Each time you telnet to a machine,
  40.    ftp to another machine, connect to the smtp port or POP port, read
  41.    news, off of a different machine, or issue Remote Procedure Calls you
  42.    hand your password and other private information to anyone who wants
  43.    to sit on the lines and listen in. There are several ways of
  44.    protecting oneself. DESLogin provides completely encrypted telnet
  45.    sessions, there is a kerberized POP server available, and there are
  46.    hardware and software utilities to do encryption on different OSI
  47.    layers. Many of these suffer from either being commercial products or
  48.    simply being too difficult to administer.
  49.    
  50.    A wonderful security tool was presented to the network community that
  51.    provides a seeming solution to having your password sniffed. The
  52.    theory behind it is to never use the same password. This is
  53.    accomplished by a challenge response system. The system you are
  54.    contacting issues you a unique challenge. You go off and compute your
  55.    response and then send back that unique response to the host. The next
  56.    time you are presented with a different challenge and thus come back
  57.    with a different response. Sounds great doesn't it? What's even better
  58.    is that the software for the server side and the client side are free
  59.    and widely available. Here's an example of what it looks like:
  60.    
  61.  
  62. madwand.l0pht.com> telnet some.host.somewhere
  63. Trying 199.99.99.99... Connected to some.host.somewhere.
  64. Escape character is '^]'.
  65.  
  66. login: jdoe
  67. s/key 99 k113355
  68. Password: WELD GUY CHIMP SWING GONE
  69.  
  70.    
  71.    
  72.    What has happened here is a telnet to a machine where S/KEY is in use.
  73.    After logging in with the username of jdoe, a challenge is issued.
  74.    jdoe computes his response on a local machine and uses that as input
  75.    for the password prompt. Let's take a look at this and figure:
  76.    
  77.  
  78. s/key 99 k113355
  79. s/key - text so the user knows what is going on.
  80. 99 - number of iterations through MD4
  81. k113355 - seed
  82.  
  83.    Assuming jdoe provided a valid response, the next time he would try to
  84.    log in the iterations counter would be decremented [i.e. s/key 98
  85.    k113355] and the response that would be computed would be different.
  86.    Thus anybody who sniffed the above [i.e. user: jdoe - Password: WELD
  87.    GUY CHIMP SWING GONE] would not be able to gain access to the machine
  88.    with this information as the password is no longer valid.
  89.    
  90.    
  91.      _________________________________________________________________
  92.    
  93. Dictionary Attacks
  94.  
  95.    
  96.      _________________________________________________________________
  97.    
  98.   A
  99.   
  100.    
  101.    One of the first vulnerabilities is that all of the information is
  102.    broadcast in plaintext. What this means is that it is trivial to take
  103.    the challenge and response and compare this with the result of the
  104.    challenge applied to words out of a dictionary.
  105.    
  106.  
  107. username: jdoe
  108. challenge: 99 k113355
  109. response: WELD GUY CHIMP SWING GONE
  110. jdoe's real password: ????
  111.  
  112. dictionary word 1: love
  113. challenge: 99 k113355
  114. response: BAD LOST CRUMB HIDE KNOT
  115. (well that's not it...)
  116.  
  117. dictionary word 2: sex
  118. challenge: 99 k113355
  119. response: FORT HARD BIKE HIT SWING
  120. (not it either...)
  121.  
  122. dictionary word 3: secret
  123. challenge 99 k113355
  124. response: WELD GUY CHIMP SWING GONE
  125. (bingo! )
  126.  
  127.    
  128.    
  129.    We now know that jdoe's real password is 'secret'. With this
  130.    information we can generate a valid response no matter what the
  131.    challenge.
  132.    
  133.    This is particularly important since in the current implementations of
  134.    the skey package neither the client or server side does any sort of
  135.    sanity check on the security of the chosen password. This means there
  136.    is no failsafe to try to prevent you from choosing your login name as
  137.    your password or other silliness.
  138.    
  139.   B
  140.   
  141.    
  142.    Another source for dictionary attacks come from the /etc/skeykeys
  143.    file. The number of sites that have skey set up that have the improper
  144.    permissions set on this file is quite surprising. This file should not
  145.    be set to world readable. While the 'keyinfo' program would like it to
  146.    be so, the harm outweighs the good. The skeykeys file looks like this:
  147.    
  148.    
  149.  
  150. root 0072 k113357          12afaa8be65f0502  Jun 29,1995 12:40:48
  151. jdoe 0099 k113355       c7f42dfd84914af3  May 30,1995 16:20:19
  152. [etc...]
  153.  
  154.    
  155.    What we have here is the username, iteration counter, seed, and a hex
  156.    representation of the five word response we saw before. The other
  157.    three fields are simply date and time information which isn't of much
  158.    interest right now. The exact same sort of dictionary hack can be made
  159.    with this information. Just to bring the point home, let's pretend you
  160.    have a large user base of say, 200 users, and since you are security
  161.    conscious you have a shadow password system and are using s/key. While
  162.    the average account will not be able to look at the real password file
  163.    since it is shadowed they will not be able to do a standard dictionary
  164.    attack on it. They will, however, be able to see the skeykeys file and
  165.    do a dictionary attack on it if the permissions are set improperly,
  166.    thus defeating the benefits of a shadowed password file.
  167.    
  168.    
  169.      _________________________________________________________________
  170.    
  171. Spoofing Attacks
  172.  
  173.    
  174.      _________________________________________________________________
  175.    
  176.    
  177.   A
  178.   
  179.    
  180.    Since the iteration counter is transmitted along with the seed, one
  181.    possibility is to masquerade as the server. This could be done by
  182.    setting up a bogus gateway or whatever. Who we are really spoofing is
  183.    the user. Let's take the following scenario...
  184.    
  185.  
  186. login: jdoe
  187. [jdoe telnet's to his machine]
  188.  
  189. s/key 55 k113355
  190. password:
  191. [what jdoe should have seen was a challenge of 98 k113355 but instead we have s
  192. ent a lower challenge of 55 k113355.]
  193.  
  194. password: MY SPIT LOFT HEAD TEAR
  195. [jdoe calculates the response for 55 k113355 based upon his secret password]
  196.  
  197. Login incorrect
  198. login:
  199. [we tell jdoe that his login was incorrect and forward the rest of the connecti
  200. on to the actual machine he really wanted to talk to in the first place]
  201.  
  202.    
  203.    With the response we have for the 55 k113355 challenge all we have to
  204.    do is run it through more iterations of md4 for the subsequent
  205.    responses. For example, with the information we have now, if we want
  206.    to figure out the response for the challenge 60 k113355 we need to run
  207.    it through 5 more iterations of md4. If we were looking for the
  208.    response to the challenge of 97 k113355 we would need to run it
  209.    through 42 more iterations of md4. etc. etc.
  210.    
  211.    We can now telnet to the machine and, as long as the iteration counter
  212.    in the challenge is above 55 k113355, we can compute the proper
  213.    response without ever having to know the secret password.
  214.    
  215.    There are many variations on the above theme...
  216.    
  217.      _________________________________________________________________
  218.    
  219. Trojan Attacks
  220.  
  221.    
  222.      _________________________________________________________________
  223.    
  224.    
  225.   A
  226.   
  227.    
  228.    This is not a problem with s/key but simply a reminder.
  229.    
  230.    The same vulnerability for trojanized login and su programs for the
  231.    s/key replacements exists as the regulars.
  232.    
  233.    
  234.      _________________________________________________________________
  235.    
  236. Race Attacks
  237.  
  238.    
  239.      _________________________________________________________________
  240.    
  241.    
  242.   A
  243.   
  244.    
  245.    There seems to be a problem with s/key that allows two simultaneous
  246.    logins to occur with the same key. If I am in a position to
  247.    capture-look at-modify jdoe's responses as they go bye (i.e. we're a
  248.    bogus gateway or something again), we can open up another telnet
  249.    session to the same machine and, since he hasn't logged in yet the
  250.    iteration counter hasn't been decremented, get the same challenge. As
  251.    we receive jdoe's response we simply send the same information over to
  252.    our other processes as well as his original login. With a little luck
  253.    a locking problem will occur with the skeykeys file and we will both
  254.    be let in under the same challenge and response. This should be easily
  255.    fixable in the source but I have not yet investigated this fully.
  256.    
  257.    
  258.      _________________________________________________________________
  259.    
  260. Hi-Jacking Attacks
  261.  
  262.    
  263.      _________________________________________________________________
  264.    
  265.   A
  266.   
  267.    
  268.    This is not a problem with s/key but simply a reminder.
  269.    
  270.    Remember that once a connection has been established and jdoe has
  271.    successfully answered the challenge with the appropriate response
  272.    there are no more checks done on the s/key side of things. It is not
  273.    designed to. It is not kerberos. People are too often lulled into
  274.    false senses of security, as in the choosing of easily guessed
  275.    passwords, when they use the s/key system. Once in, the same IP
  276.    Hi-jacking and monitoring tricks can be used on jdoe's session as can
  277.    be used on non-s/key sessions.
  278.    
  279.    
  280.      _________________________________________________________________
  281.    
  282. Outro
  283.  
  284.    
  285.      _________________________________________________________________
  286.    
  287.    
  288.    I like s/key. I think s/key is a very good utility and a great asset
  289.    to the community in general. This paper should not dissuade anyone
  290.    from using s/key. It is simply meant to point out certain
  291.    vulnerabilities. The worst thing that can happen to a the security
  292.    conscious is a false sense of security. While s/key does provide added
  293.    security, neither it nor any other product currently out on the market
  294.    is the be-all end-all to security. If this paper has helped to remind
  295.    anyone of this then it has done it's job.
  296.    
  297.    
  298.     -Mudge
  299.     mudge@l0pht.com
  300.